In a conventional cryptographic file system, the data (or files) are stored encrypted. This is a convenient feature especially if an owner of the files cannot trust the administrator of the server to provide adequate security measures to ensure data privacy. To make the conventional cryptographic file system more user-friendly, users typically try to minimize the number of cryptographic keys used to encrypt the files. Otherwise, the number of cryptographic keys may be equal to the number of files that the owner/user may have on the cryptographic keys, which may make managing the cryptographic keys burdensome, and thereby making the cryptographic file system less user-friendly.
In some cases, users share files in a cryptographic file system by having a copy of the encrypted file and an associated decryption key. In this manner, a user may utilize the associated decryption key to decrypt the received encrypted file for access to the file. However, in some instances, an owner of a file may attempt to prevent a previously authorized user from future access to the file, i.e., revoke a user.
One method for revoking a user by an owner of the file is to re-encrypt all the files of the owner with a new cryptographic key. However, re-encrypting all the files is a time-consuming and burdensome task, especially if the owner has encrypted a number of files with the same cryptographic key.
Another solution for revoking a user is described in “Group Sharing and Random Access in Cryptographic Storage File Systems,” Master's Thesis, Department of EECS, MIT June 1999, written by Kevin Fu, which is hereby incorporated by reference in its entirety. This solution proposes a technique called lazy revocation where files are to be re-encrypted with a different key only when the file is updated. Accordingly, a revoked user is unable to view any updates to the file. In particular, Fu proposes utilizing a ‘lock-box’. The cryptographic key used to encrypt a file is stored in the lockbox. The lockbox is also encrypted with another cryptographic key that is stored in a trusted group server. In the event of a user revocation, all the lockboxes that the revoked user had access to are marked as ‘dirty’ and any subsequent updates to any dirty file causes that file to be re-encrypted.
Although Fu's design is an adequate solution, the design may have some drawbacks as applied to different types of cryptographic file system architectures. For instance, in a cryptographic system where the file server cannot be trusted (or required) to perform user authentication, Fu's proposal may generate a substantial amount of work for a file owner. In particular, in Fu's proposal, the file server and/or group server are guaranteed that a revoked user (or unauthorized user) cannot see the contents of an encrypted file. In order to meet his constraint in an untrusted server environment, Fu's design can provide security if the design is extended such that the owner changes the group key (in the group server) and re-encrypts all the lockboxes at the time of revocation. Accordingly, this makes revocation expensive in terms of user time and computational resources, especially if the revoked user had access to a large number of files. In essence, this constraint allows lockboxes to perform lazy-re-encryption of the files, but requires immediate re-encryption of the lockboxes as opposed to a more ideal scenario where the revocation process does not interrupt the file owner. Further, since there are now two encryption keys for this file—the current and the former key—additional key storage is required. Further, when a second revocation occurs, the current key becomes the former key and any files protected with the former key must be aggressively re-encrypted.
In general, other conventional secure systems that provide revocation rely on the server checking for user's group membership before granting access. This particular trait requires the servers to store (or cache) information regarding users, which places a high trust requirement on the servers and requires all the servers to maintain this authentication information in a secure and consistent manner.
Other conventional techniques securely send every key update to the user, such that the user is able to decrypt files encrypted with various versions of the key. Unfortunately, the user may fail to receive one or more of the keys. This may be due to the owner being unable to achieve a secure connection to the user when the key updates are provided or simply due to a failure in transferring the new key. In this case, the user is unable to decrypt files for which he lacks the proper key.
Thus, one problem with some conventional methods and systems for providing cryptographic key management is that all of the files need to be re-encrypted with the new key, whenever a new key is needed. Another problem with some conventional methods and systems for providing cryptographic key management is that the user is unable to decrypt files because a new key was not received.